Method and system for arbitraging computing resources in a cloud computing environment

ABSTRACT

Disclosed is are methods and systems for processing a workload among a plurality of computing resources that optimizes the processing price per workload. The method includes breaking the workload into two or more tasks each having a size optimized based on (i) a price history of one or more of the plurality of computing resources and (ii) a predicted duration to complete processing of each of the respective tasks; and sending one of the two or more tasks to a computing resources for which the size of the tasks is optimized.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to and the benefit of U.S. ProvisionalPatent Application Ser. No. 61/349,877, filed on May 29, 2010, entitled,“Method and System for Arbitraging Computing Resources In A CloudComputing Environment,” and which is hereby incorporated by reference inits entirety.

FIELD OF THE INVENTION

The invention relates to data processing. In particular, systems andmethods consistent with the present invention relate to allocation ofresources in a cloud computing environment.

BACKGROUND OF THE INVENTION

“Cloud computing” refers to the access of computing resources and datavia a network infrastructure, such as the Internet. The computingresources and data storage may be provided by linked data centers of the“cloud,” i.e., network. Each of the data centers may include a pluralityof servers that provide computing resources, as well as data storage andretrieval capabilities. Users of cloud computing generally do not needknowledge regarding or control over the underlying data centerinfrastructure of the “cloud”. Rather, the users may purchase,subscribe, or lease the computing resources and data storagecapabilities on an as-needed and ‘pay as you go’ basis.

When a user requests access to the computing resources, the user mayrequest access based on a set of service level requirements, and apricing agent managing access to the computing resources will provide aprice to service the user's request. Some systems allow a user toprovide a bid with a request. The bid being a suggested price that theuser will pay for the purchase, subscription, or lease of the computingresources. In such a system, the pricing agent managing access to thecomputing resources will accept the bid or reject the bid. Uponrejection of the bid, the user can submit another bid or the pricingagent may submit a counter-bid.

Whether a pricing agent will accept the user's bid may change throughoutthe day or relevant time cycle. Typically, the value of an accepted bidincreases during peak demand, and decreases when there is slack in thedemand for the computing resources. Demand for the computing resource atdifferent data centers will also vary at any given point in time. Thismeans that at any given time T₁, the accepted bid at datacenter Alpha,P_(A), and the accepted bid at data center Beta, P_(B), may differ bysome value Δ_(P). Although described with reference to two data centers,the example would be the same if one data center offered two differentservice levels, A and B.

Another characteristic of cloud computing is that the pricing may bestatic or dynamic. In a static pricing model, the computing resourcesare available for the contract period and accepted bid price. In adynamic pricing model, the computing resources are available only solong as the pricing agent does not receive a higher competing bid. Thus,in a dynamic pricing model, a user may lose a computing resourcemid-processing cycle if a higher bidder requests access. Upon losing thecomputing resource, the user may either increase his bid or lengthen hisprocessing term to increase the likelihood that demand will drop and hiswill become the highest bid.

Another problem with operating under a dynamic pricing model is that itis difficult for a user to select among available (typically competing)data centers, each offering computing resources. The average usertypically does not have the information necessary to predict how demand,and therefore price, will change over time for each data center'scomputing resources. For example, while data center Alpha may accept anlower bid, initially, than data center Beta, over a time cycle (e.g., aday), data center B may be cheaper because a large, cost insensitive,consumer of computing resources typically demands data center Alpha'scomputing resources for 40% of each time cycle.

Thus, there is a need for a tool the allow users to manage their costsand time horizons when using computing resources offered on a dynamicpricing model.

BRIEF SUMMARY OF THE INVENTION

The invention is a method and system for arbitraging computing resourcesin a cloud computing environment. An objective of the present inventionis to find the most economical time to schedule processes in a cloudcomputing environment. Another objective of the present invention is todetermine the optimal time frame for processing data in a cloudcomputing environment.

The present disclosure is directed to implementations of a method andsystem for arbitraging computing resources in a cloud computingenvironment. More specifically, the present invention is directed atusing historical pricing and processing data produced from a cloudcomputing environment to calculate optimal bid pricing and processingtimes. According to first exemplary embodiment of the invention, thereis provided a method for processing a workload among a plurality ofcomputing resources. The method includes breaking the workload into twoor more tasks each having a size optimized based on (i) a price historyof one or more of the plurality of computing resources and (ii) apredicted duration to complete processing of each of the respectivetasks; and sending one of the two or more tasks to computing resourcesfor which the size of the tasks is optimized.

In one aspect of this first exemplary embodiment, the method furtherincludes purchasing compute time from the computing resource to whichthe task is sent.

In another aspect of this first exemplary embodiment, the method furtherincludes selecting a price history based on a stored profile associatedwith a user.

In another aspect of this first exemplary embodiment, the stored profileis also associated with one of the plurality of computing resources.

In another aspect of this first exemplary embodiment, the method furtherincludes selecting a price history based on a stored profile associatedwith a second user different from a first user that requests processingof the workload.

In another aspect of this first exemplary embodiment, the method furtherincludes collecting information related to processing of the workload;and modifying the stored profile based on the collected information.

In another aspect of this first exemplary embodiment, the stored profilehas associated with it attributes, the attributes comprising one or moreof: average work load size, average historical processing time, pricefluctuations, type of information processed, and combinations thereof.

In another aspect of this first exemplary embodiment, the method furtherincludes, receiving a bid and a designated duration; and providing theuser an indication of the probability that the workload will beprocessed at the bid price and within the designated duration.

In another aspect of this first exemplary embodiment, the method furtherincludes calculating the probability according to the function:

${{P(A)} = \frac{n(A)}{n(S)}},$

where n(A) is occurrences of workloads completing during the designatedduration, and n(S) is the sum of the occurrences of workloads completingduring the designated duration and the occurrences of workloads failingto complete during the designated duration.

According to a second exemplary embodiment of the invention, there isprovided a system for processing a workload among a plurality ofcomputing resources. The system includes, a workload packaging modulethat breaks the workload into two or more tasks each having a sizeoptimized based on (i) a price history of one or more of the pluralityof computing resources and (ii) a predicted duration to completeprocessing of each of the respective tasks; and a workload schedulingmodule that queues the tasks having the optimized size for the computingresources.

In an aspect of this second exemplary embodiment, the system furtherincludes a workload buying module that purchases compute time from thecomputing resources for which a task is queued.

In another aspect of this second exemplary embodiment, the workloadpackaging module selects a price history based on a stored profileassociated with a user.

In another aspect of this second exemplary embodiment, the storedprofile is also associated with one of the plurality of computingresources.

In another aspect of this second exemplary embodiment, the workloadpackaging module selecting a price history based on a stored profileassociated with another user different from the user.

In another aspect of this second exemplary embodiment, the workloadpackaging module, collects information related to processing of theworkload; and modifies the stored profile based on the collectedinformation.

In another aspect of this second exemplary embodiment, the storedprofile has associated with it attributes, the attributes comprising oneor more of: average work load size, average historical processing time,price fluctuations, type of information processed, and combinationsthereof.

In another aspect of this second exemplary embodiment, the systemfurther includes a probability calculator that receives a bid and adesignated duration, and provides a user an indication of theprobability that the workload will be processed at the bid price andwithin the designated duration.

In another aspect of this second exemplary embodiment, the probabilitycalculator calculates the probability according to the function:

${{P(A)} = \frac{n(A)}{n(S)}},$

where n(A) is occurrences of workloads completing during the designatedduration, and n(S) is the sum of the occurrences of workloads completingduring the designated duration and the occurrences of workloads failingto complete during the designated duration.

In another aspect of this second exemplary embodiment, the systemfurther includes a workload status monitoring module that monitors thestatus of tasks executing at the plurality of computing resources.

In another aspect of this second exemplary embodiment, the systemfurther includes the workload status monitoring module stopping theexecution of a task, and moving the task to a different computingresource.

In another aspect of the second exemplary embodiment, modifying thestored profile based on the collected information comprises updating thestored profile with data gathered during processing of the user'sworkload.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is described with reference to the accompanyingdrawings. In the drawings, like reference numbers indicate identical orfunctionally similar elements. The drawings are not drawn to scale.

FIG. 1 is a functional block diagram of a system for arbitragingcomputer resources in a cloud computing environment in accordance withan illustrative embodiment of the present invention.

FIG. 2 is a chart illustrating a historical pricing curve in accordancewith an illustrative embodiment of the present invention.

FIG. 3 is a block diagram illustrating providers that publish pricehistory in accordance with an illustrative embodiment of the presentinvention.

FIG. 4 is a block diagram illustrating a consumer observing pricehistory in accordance with an illustrative embodiment of the presentinvention.

FIG. 5 is a block diagram illustrating a system for processing consumerworkloads in accordance with an illustrative embodiment of the presentinvention.

FIG. 6 is a block diagram illustrating the modules of a workloadarbitrage engine optimizer in accordance with an illustrative embodimentof the present invention.

FIG. 7 is a block diagram illustrating the steps of a workload arbitrageoptimization method in accordance with an illustrative embodiment of thepresent invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention will now be described more fully in detail withreference to the accompanying drawings, in which the preferredembodiments of the invention are shown. This invention should not,however, be construed as limited to the embodiments set forth herein;rather, they are provided so that this disclosure will be complete andwill fully convey the scope of the invention to those skilled in theart.

The terms “user” and “consumer” are used interchangeably throughout theDetailed Description.

FIG. 1 illustrates an exemplar system for arbitraging computer resourcesin a cloud computing environment 100. The exemplar system 100 includes acomputer 103 a computing arbitrage server 101, a plurality of cloudcomputing environments 104, 105, and a network 106. The computingarbitrage server 101 may generate and/or populate a database 102 throughthe network 106, as described in further detail herein. Although thedatabase 102 is illustrated external to the computing arbitrage server101, it is contemplated that the database 102 may be an integralcomponent of the computing arbitrage server 101, and/or be resident in aseparate memory, or an electronic storage medium (e.g. server) thatcommunicates with the computing arbitrage server 101. The computingarbitrage server 101 may communicate with the computer 103 and/or aplurality of cloud computing environments 104, 105 through the network106. The network 106 may include, but is not limited to, a local areanetwork (LAN), a wide area network (WAN), a wireless LAN (WLAN), ametropolitan area network (MAN), a personal area network (PAN), cellularnetwork, the Internet, and/or combinations thereof. The computers 101and 103, and the cloud computing environments 104 and 105 may beconnected over the Internet, an Intranet, Extranet, Ethernet, or anyother system that provides communications. Some suitable communicationsprotocols may include TCP/IP, UDP, or OSI for example. For wirelesscommunications, communications protocols may include Bluetooth, Zigbee,IrDa or other suitable protocol. Furthermore, components of the systemmay communicate through a combination of wired or wireless paths.

The computers 101 and 103 may include a processing unit, a systemmemory, and a system bus that couples various system componentsincluding the system memory to the processing unit. The computers 101and 103 may include a variety of computer readable media that can formpart of the system memory and be read by the processing unit. By way ofexample, and not limitation, computer readable media may comprisecomputer storage media and communication media. The system memory mayinclude computer storage media in the form of volatile and/ornonvolatile memory such as read only memory (ROM) and random accessmemory (RAM). A basic input/output system (BIOS), containing the basicroutines that help to transfer information between elements, such asduring start-up, is typically stored in ROM. RAM typically contains dataand/or program modules that are immediately accessible to and/orpresently being operated on by processing unit. The data or programmodules may include an operating system, application programs, otherprogram modules, and program data. The operating system may be orinclude a variety of operating systems such as Microsoft Windows®operating system, the Unix operating system, the Linux operating system,the Xenix operating system, the IBM AIX™ operating system, the HewlettPackard UX™ operating system, the Novell Netware™ operating system, theSun Microsystems Solaris™ operating system, the OS/2™ operating system,the BeOS™ operating system, the Macintosh™® operating system, theApache™ operating system, an OpenStep™ operating system, iOS™ operatingsystem, Android™ operating system, or another operating system ofplatform.

At a minimum, the memory includes at least one set of instructions thatis either permanently or temporarily stored. The processor executes theinstructions that are stored in order to process data. The set ofinstructions may include various instructions that perform a particulartask or tasks, such as those shown in the appended flowcharts. Such aset of instructions for performing a particular task may becharacterized as a program, software program, software, engine, module,component, mechanism, or tool.

The computers 101 and 103 may include a plurality of software processingmodules stored in a memory as described above and executed on aprocessor in the manner described herein. The program modules may be inthe form of any suitable programming language, which is converted tomachine language or object code to allow the processor or processors toread the instructions. That is, written lines of programming code orsource code, in a particular programming language, may be converted tomachine language using a compiler, assembler, or interpreter. Themachine language may be binary coded machine instructions specific to aparticular computer.

Any suitable programming language may be used in accordance with thevarious embodiments of the invention. Illustratively, the programminglanguage used may include assembly language, Ada, APL, Basic, C, C++,COBOL, dBase, Forth, FORTRAN, Java, Modula-2, Pascal, Prolog, REXX,Ruby, Clojure, and/or JavaScript for example. Further, it is notnecessary that a single type of instruction or programming language beutilized in conjunction with the operation of the system and method ofthe invention. Rather, any number of different programming languages maybe utilized as is necessary or desirable.

The processing unit that executes commands and instructions may be ageneral purpose computer, but may utilize any of a wide variety of othertechnologies including a special purpose computer, a microcomputer,mini-computer, mainframe computer, programmed micro-processor,micro-controller, peripheral integrated circuit element, a CSIC(Customer Specific Integrated Circuit), ASIC (Application SpecificIntegrated Circuit), a logic circuit, a digital signal processor, aprogrammable logic device such as an FPGA (Field Programmable GateArray), PLD (Programmable Logic Device), PLA (Programmable Logic Array),RFID integrated circuits, smart chip, or any other device or arrangementof devices that is capable of implementing the steps of the processes ofthe invention.

It should be appreciated that the processors and/or memories of thecomputer system need not be physically in the same location. Each of theprocessors and each of the memories used by the computer system may bein geographically distinct locations and be connected so as tocommunicate with each other in any suitable manner. Additionally, it isappreciated that each of the processor and/or memory may be composed ofdifferent physical pieces of equipment.

A user may enter commands and information into the computers 101 and 103through a user interface that includes input devices such as a keyboardand pointing device, commonly referred to as a mouse, trackball or touchpad. Other input devices may include a microphone, joystick, game pad,satellite dish, scanner, voice recognition device, keyboard, touchscreen, toggle switch, pushbutton, or the like. These and other inputdevices are often connected to the processing unit through a user inputinterface that is coupled to the system bus, but may be connected byother interface and bus structures, such as a parallel port, game portor a universal serial bus (USB).

The plurality of cloud computing environments 104, 105 may provideshared computing resources, software and information to the computer 103and computing arbitrage server 101 on an as-needed basis. For instance,a cloud computing environment 101 may be used to process large amountsof data for a computer 103 which does not have the appropriate computingcapacity for the task. In this example the cloud computing environment104 provides computer infrastructure services for the computer 103.

In one embodiment, the cloud computer environments 104 and 105 use astatic pricing model. In another embodiment, the cloud computerenvironments 104 and 105 use a dynamic pricing model.

In implementations of the present invention, the computing arbitrageserver 101 may execute processes for arbitraging computer resources in acloud computing environment. More specifically, and as described infurther detail herein, the computing arbitrage server 101 collectshistorical pricing and processing data produced from a cloud computingenvironment to calculate optimal bid pricing and processing times.

FIG. 2 illustrates a historical pricing curve 200 in accordance with anillustrative embodiment of the present invention. Cloud infrastructureservices are typically priced and billed on a utility computing basis.The amount of resources consumed and pricing will reflect the level ofactivity within the cloud computing environment. The pricing curve 200charts the available computing capacity of a cloud environment over aperiod of time 202 (x-axis) and the price associated 201 (y-axis) withusing the capacity. For instance, during the morning time period thecapacity utilization for the cloud computing environment is at themaximum with a maximum price associated of $0.50 204. In order tomaximize the most economical and efficient use of computing resources,processing time periods 204 are determined that lay outside the high use(and therefore high cost) times.

In one embodiment, the historical price information is published by thesuppliers of the computing resources. In another embodiment, thehistorical price information is observed and stored by the computingarbitrage server 101. In a third embodiment, the historical priceinformation is a combination of the published price histories and theobserved price histories.

FIG. 3 illustrates providers 301, 303 and 305 that publish pricehistories 302, 304, and 306 in accordance with an illustrativeembodiment of the present invention. A provider 301, 303, 305 is asupplier of computing resources (e.g., a data center), typically a‘compute cycle processing hour’. Some providers 301, 303, 305 makeavailable a history of pricing information detailing compute pricinginformation 302, 304, 306. This information includes but is not limitedto price per CPU hour, time of day price is available, and duration theprice per hour is offered.

FIG. 4 illustrates a system 400 that includes a consumer 401, and aconsumer observed price history 402, 403 and 404 to process a workloadin accordance with an illustrative embodiment of the present invention.A consumer 401 is an entity purchasing compute processing from aprovider. The consumer 401 is associated with a price history 402, 403,404 for each provider. The published price history 302, 304, 306 andobserved price history 402, 403, 404 are used to make buying decisionsregarding compute processing.

A workload is a defined amount of work (i.e., a task to be executed bythe compute processing services of a provider) to be processed by acomputer provider for the consumer. A workload has a typical time (e.g.duration) associated with it. The terms “job” and “workload” aresynonymous in this embodiment.

FIG. 5 illustrates a system for processing consumer workloads 500 inaccordance with an illustrative embodiment of the present invention. Thesystem for processing consumer workloads 500 comprises a processedworkload timing history module 501, a workload types and prioritiesmodule 502, an on-demand workload queue 503 and a scheduled workloadqueue 504. The processed workload timing history module 501 maintains adatabase of all previous jobs that includes information not limited tothe type of job, the duration of the job, and cross-references theinformation with the provider history. The workload types and prioritiesmodule 502 categorizes workload tasks and assigns a priority level andtypical duration. The priority level and duration are variables used bya scheduler in a purchasing calculation in accordance with an embodimentof the present invention. An on-demand workload queue module 503 is alist of tasks that are not previously scheduled. This is a list of“ad-hoc” work to be performed. A scheduled workload queue module 504 isa list of previously scheduled tasks.

FIG. 6 illustrates the modules of a workload arbitrage engine optimizer600 in accordance with an illustrative embodiment of the presentinvention. The workload arbitrage engine optimizer (WAEO) 601 comprisesa workload buyer module 602, a workload packager module 604, a workloadscheduler 604, and a workload status monitor module 605. These modulesmight be instantiated by one or more computer processes running on asingle computer or across a distributed platform. Specific embodimentswill be described further below.

The workload arbitrage engine and optimizer 601 is a collection ofmodules that manages duties including but not limited to the purchase ofcompute processing units 602, packaging jobs by optimizedduration/price/priority levels 603, executing jobs 604 at a provider301, 303, 305, monitoring job progress, restarting jobs, and moving jobs605 to another provider 301, 303, 305. The goal of the workloadarbitrage engine and optimizer 601 is to seek the lowest computeprocessing price per workload. The workload packager module 603 breaksup larger tasks therefore optimizing the duration (i.e. expected time tocompletion) with the provider pricing history duration for jobs ofsimilar types. For example, assume a workload will take two hours toprocess. Computing resource Provider 301 consistently charges $0.45 forevery second of processing time due to very consistent demand. Computingresources Provider 302 is subject to more variable demand and typicallycharges $0.30 for every second of processing time for the first halfhour at 2 AM, 4 AM 10 AM and 11 PM. In this example, the workloadpackager module 603 determines from the published pricing histories thatthe optimal price will be achieved by breaking the workload into fourtasks, each 30 minutes in processing time.

In one embodiment, the workload arbitrage engine and optimizer 601 takesinto account observed price histories 402, 403 and 404. The observedprice histories 402, 403 and 404 include information that provides ahistorical record of past workloads processed for the consumer 401. Eachconsumer 401 may have an unlimited number of observed price histories.In one embodiment, observed price histories 402, 403, and 404 are eachassociated with a different Provider 301, 303 and 305. In anotherembodiment, observed price histories 402, 403, and 404 are eachassociated with a different data type (e-mail data, document data,billing data, cell phone data, etc.). In yet another embodiment,observed price histories 402, 403, and 404 are each associated withstandard amounts of data. While observed pricing histories 402, 403, and404 are illustrated in FIG. 4 as three different storage devices, theobserved pricing histories could be stored on a single storage device,in one or more databases, and indexed according to attributes such asthe provider, data type, or amount of data. One of ordinary skill in theart would understand that these three attributes are not the onlyattributes according to which an observed pricing history could bestored or indexed.

In one embodiment, the particular consumer requesting access toProviders 301, 303, and 305 does not have an associated price history.This might be the case if the consumer is a new consumer and would nothave any observed price history. In this embodiment, the workloadarbitrage engine and optimizer 601 may match a profile of the newconsumer to a profile of a consumer that has an associated observedprice history. The workload arbitrage engine and optimizer 601 mayselect the existing profile based on attributes of the new customer thatthe workload arbitrage engine and optimizer 601 collects from the newconsumer via an interface (e.g., web form). The attributes may consistof as little as the type of business operations of the new customer(e.g., wireless services provider), or it may be very detailed,including the size of the new consumer's business operations, number ofcustomers, number of employees, the size of its enterprise operations,types of data in a typical workload, amount of data in a typicalworkload, etc. The collected attributes are matched to an existingprofile, and therefore, existing observed price histories associatedwith that existing profile. In one embodiment, the observed pricehistories associated with the existing profile become the initialobserved price histories of the new customer. As the new customerprocesses workloads using the present system, the initial observed pricehistories are modified according to the new consumer's processingresults. One of ordinary skill in the art would understand that anyattributes may be gathered from the new consumer that will help theworkload arbitrage engine and optimizer 601 select an existing profilethat closely matches the new consumer.

Once the workload arbitrage engine and optimizer 601 has loaded thepublished price history for the various providers and loaded theobserved price history (if one is available), workload arbitrage engineand optimizer 601 may proceed to determine the optimal sizes anddistributions to achieve the lowest compute processing price perworkload.

In one embodiment, the workload arbitrage engine and optimizer 601determines the average price per workload based on the observed pricehistory. For example, assume a consumer's typical workload is to index1,000,000 documents. From the observed price history it is apparent thatthe historical processing time average has been 30,000 documents indexedper minute. The historical compute provider pricing average for thisworkload has been $0.60 per minute at standard immediate processingrates. So, the expected expense is (1,000,000/30,000)×$0.60=$19.98.

This is a very simple example. In a more complicated example, theworkload arbitrage engine and optimizer 601 will load published pricinghistories 302, 304 and 305, for providers 301, 303, and 305,respectively. The published pricing histories have historical pricingdata that show, for example, that the cost per compute minute variesthroughout the day for each provider 301, 303, and 305. For example, forprovider 301, the cost per compute minute may vary from $0.20 to $0.84,for provider 301, the cost per compute minute may vary from $0.30 to$0.90, and for provider 303, the cost per computer minute may vary from$.0.15 to $0.98. Because the price per compute minute varies at eachprovider and across all three providers, there is an opportunity tooptimize the compute processing price per workload by breaking up theworkload and distributing it among the three providers. The workloadarbitrage engine and optimizer 601 iteratively churns through each usecase until it optimizes the number of tasks, the size (e.g., theduration to process) of each task, and an assigned time (by day, hour,minute and/or second) to process each task at the three providers. Inone embodiment, the workload arbitrage engine and optimizer 601 canoptimize to such a fine granularity that it will determine when to stopprocessing a task at one provider, repackage it, and move the repackagedtask to a different provider. The workload status monitor 605 monitorsthe processing status of the tasks, stops the task, and moves the taskto a different provider of computing resources. The workload statusmonitor 605 may rely on an optimization plan or schedule created at theend of the optimization process described, above, to determine when tostop, start, and move tasks for processing.

Once the compute processing price per workload is optimized the systempresents the expected processing price and duration to the user via aninterface. The user, via the same or a different interface, eitheraccepts or declines the processing at the proposed price and duration.The user can also tell the system to automatically select the bidwithout approvals—“automatic mode.”

If the user accepts the proposed processing price and duration, theworkload scheduler module 604 uses the job priority and provider pricinghistory to schedule the current workload queues as a continuous process.The workload buyer module 602 purchases and initiates jobs with aprovider 301, 303, 305. The workload status monitor module 605 checksthe status of current running tasks in order to look for jobs that couldbe stopped at a provider 301, 303, 305. In addition, the workload statusmonitor module 605 moves and restarts jobs from one provider to another301, 303, 305.

FIG. 7 illustrates the steps of a workload arbitrage optimization method700 in accordance with an illustrative embodiment of the presentinvention. The first step is to analyze published pricing historicaldata to establish a pricing curve 701. Next, an optimization algorithmis created that finds the best workload processing times according tothe pricing curve 702. Workload tasks are packaged into small andoptimized work bundles 703. The spot price is set and the work is ready“to go” 704. The final step prepares for a bid to be exceeded and workto stop, pause, restart, and/or move based on the outcome of the bidprocess 705.

In another embodiment, a consumer submits a bid price and a proposedduration. The option to submit a bid price and a proposed duration maybe presented to the consumer in the form of two slide bars on a userinterface. The consumer manipulates the sliding scales to a particularbid price and duration, for example, $10 per workload and 9 hours. Inreal-time, the arbitrage engine and optimizer 601 determines all of theoptimized processing price per workload given the consumer's particularconstraints, and presents via the same or another interface theprobability that the consumer's workload will be processed within theproposed duration and for the bid price. Typically, when the consumerincreases the bid price and proposed duration, the probability increasesthat the workload will be processed within the set constrains. Theprobability is determine according to the function:

$\begin{matrix}{{P(A)} = \frac{n(A)}{n(S)}} & {{Equation}\mspace{14mu} 1}\end{matrix}$

n(A) is occurrences of workloads completing during the designatedduration, and n(S) is the sum of the occurrences of workloads completingduring the designated duration and the occurrences of workloads failingto complete during the designated duration.

Once the consumer has satisfied their personal threshold for price,duration, and probability of successfully meeting the price andduration, the consumer accepts and the arbitrage engine and optimizer601 and the workload is processed.

As already stated, the present invention may be implemented in digitalelectronic circuitry, in computer hardware, firmware, software, or incombinations thereof. The invention may be implemented as a computerprogram product. A computer program, may be written in any form ofprogramming language, including compiled or interpreted languages, andmay be deployed in any form, including as a stand-alone program, as amodule, component, subroutine, or other unit suitable for use in acomputing environment. A computer program may be deployed or be executedon one computer, on multiple computers at one site, or distributedacross multiple sites and interconnected by a communication network.

Method steps of the present invention may be performed by one or moreprogrammable processors executing a computer program product to performfunctions of the present invention by operating on input data andgenerating output data. Method steps may also be performed by, and anapparatus of the present invention may be implemented as, specialpurpose logic, circuitry, e.g., FPGA (field programmable gate array) oran ASIC (application-specific integrated circuit)).

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andany one or more processors of any kind of digital computer. Generally, aprocessor will receive instructions and data from a read-only memory ora random access memory or both. The essential elements of a computer area processor for executing instructions and one or more memory devicesfor storing instructions and data. Generally, a computer will alsoinclude, or be operatively coupled to receive data from or transfer datato, or both, one or more mass storage devices for storing data, e.g.,EPROM, and flash memory devices; magnetic disks such as internal harddisks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROMdisks. The processor and the memory may be supplemented by, orincorporated in special purpose logic circuitry.

The present invention may be implemented in a system including, but notlimited to the systems described herein, which include: a back-endcomponent, (e.g., a data server), middleware component (e.g.,application server) or a front-end component (e.g., a client devicehaving a graphical user interface or a Web browser through which a usermay interact with an implementation of the invention), or anycombination of such back-end, middleware, or front-end components. Thecomponents of the system may be interconnected by any form or medium ofdigital data communication (e.g., a communication network).

It is understood that the embodiments described herein are merelyillustrative of the present invention. Variations in the construction ofthe method and system for arbitraging computer resources in a cloudcomputing environment may be contemplated by one skilled in the artwithout limiting the intended scope of the invention herein disclosed.

1. A method for processing a workload among a plurality of computingresources, the method comprising: breaking the workload into two or moretasks each having a size optimized based on (i) a price history of oneor more of the plurality of computing resources and (ii) a predictedduration to complete processing of each of the respective tasks; andsending one of the two or more tasks to a computing resources for whichthe size of the tasks is optimized.
 2. The method of claim 1, furthercomprising purchasing compute time from the computing resource to whichthe task is sent.
 3. The method of claim 1, further comprising selectinga price history based on a stored profile associated with a user.
 4. Themethod of claim 3, wherein the stored profile is also associated withone of the plurality of computing resources.
 5. The method of claim 1,further comprising selecting a price history based on a stored profileassociated with a second user different from a first user that requestsprocessing of the workload.
 6. The method of claim 5, furthercomprising: collecting information related to processing of theworkload; and modifying the stored profile based on the collectedinformation.
 7. The method of claim 5, wherein the stored profile hasassociated with it attributes, the attributes comprising one or more of:average work load size, average historical processing time, pricefluctuations, type of information processed, and combinations thereof.8. The method of claim 1, further comprising: receiving a bid and adesignated duration; and providing the user an indication of theprobability that the workload will be processed at the bid price andwithin the designated duration.
 9. The method of claim 8, furthercomprising calculating the probability according to the function:${{P(A)} = \frac{n(A)}{n(S)}},$ where n(A) is occurrences ofworkloads completing during the designated duration, and n(S) is the sumof the occurrences of workloads completing during the designatedduration and the occurrences of workloads failing to complete during thedesignated duration.
 10. A system for processing a workload among aplurality of computing resources, the system comprising: a workloadpackaging module that breaks the workload into two or more tasks eachhaving a size optimized based on (i) a price history of one or more ofthe plurality of computing resources and (ii) a predicted duration tocomplete processing of each of the respective tasks; and a workloadscheduling module that queues the tasks having the optimized size forthe computing resources.
 11. The system of claim 10, further comprisinga workload buying module that purchases compute time from the computingresources for which a task is queued.
 12. the system of claim 10,wherein the workload packaging module selects a price history based on astored profile associated with a user.
 13. The system of claim 12,wherein the stored profile is also associated with one of the pluralityof computing resources.
 14. The system of claim 10, wherein the workloadpackaging module selecting a price history based on a stored profileassociated with another user different from the user.
 15. The system ofclaim 14, wherein the workload packaging module, collects informationrelated to processing of the workload; and modifies the stored profilebased on the collected information.
 16. The system of claim 14, whereinthe stored profile has associated with it attributes, the attributescomprising one or more of: average work load size, average historicalprocessing time, price fluctuations, type of information processed, andcombinations thereof.
 17. The system of claim 10, further comprising aprobability calculator that receives a bid and a designated duration,and provides a user an indication of the probability that the workloadwill be processed at the bid price and within the designated duration.18. The system of claim 17, wherein the probability calculatorcalculates the probability according to the function:${{P(A)} = \frac{n(A)}{n(S)}},$ where n(A) is occurrences ofworkloads completing during the designated duration, and n(S) is the sumof the occurrences of workloads completing during the designatedduration and the occurrences of workloads failing to complete during thedesignated duration.
 19. The system of claim 10, further comprising aworkload status monitoring module that monitors the status of tasksexecuting at the plurality of computing resources.
 20. The system ofclaim 19, further comprising the workload status monitoring modulestopping the execution of a task, and moving the task to a differentcomputing resource.
 21. The system of claim 15, wherein modifying thestored profile based on the collected information comprises updating thestored profile with data gathered during processing of the user'sworkload.